Entladen unter Postgres oder Informix / UNIX

 

Am einfachsten ist es, wenn Sie als User superx vom SuperX-Server direkt auf den SOS-Datenbankserver zugreifen und entladen können ("Pull"-Verfahren). Dann ist es sogar egal ob Sie SOS unter Informix f. Win., Informix f. Unix oder Postgres einsetzen; außerdem brauchen Sie die Dateien dann nicht vom SOS-Rechner nach SuperX kopieren.

Für Postgres ist dies auch deshalb die einfachste Lösung, weil zum Entladen aus Postgres die Bibliotheken des SuperX-Kernmoduls vorhanden sein müssen.

Für Informix ist auch das Entladen im "Push"-Verfahren möglich: kopieren Sie den gesamten Verzeichnisinhalt ab $SOS_PFAD/rohdaten auf den SOS-Rechner, geben Sie dem Script Ausführungsrechte. Die Scripte laufen nur, wenn die entsprechenden Umgebungsvariablen in der Datei SOS_ENV (im gleichen Verzeichnis, ein Muster liegt vor in SOS_ENV.sam) korrekt gesetzt sind, benennen Sie die Musterdatei um nach SOS_ENV und tragen die richtigen Umgebungsvariablen ein, z.B. den Pfad für $INFORMIXDIR, und das Semester, ab wann Sie entladen wollen (start_stud_sem bzw. start_pruef_sem).

SOS_ENV
Die Umgebung für Entladescripte aus SOS
(Auszug)

##Pfad für Entladedaten:

SOS_PFAD=.   ; export SOS_PFAD 

##hier muss Unterverzeichnis unl existieren!

 

#ab hier werden Daten ausgewertet:

start_stud_sem = 19881 #sos-studenten und fächer

start_pruef_sem = 19921 #Prüfungen    

SOS_UNL_COMPLETE=true

export SOS_UNL_COMPLETE

Am besten nehmen Sie für den Testbetrieb nur ein paar Semester, denn wenn Sie weiter in die Vergangenheit zurückgehen, dann laufen die Scripte recht lange.

In der  SOS_ENV müssen  folgende Umgebungsvariablen gesetzt werden (defaults sind bereits vorbelegt, aber hier und da müssen Sie sicher ran):

 

 

Nur für Informix gelten:

INFORMIXDIR

Home-Verzeichnis von Informix

INFORMIXSERVER

Name des Informixservers

ONCONFIG

Name der onconfig, wenn  auf dem SOS-Rechner mehrere Informix-Instanzen laufen

CLIENT_LOCALE

Sprachumgebung (wichtig fürs Entladen von Datumsformaten)

SERVER_LOCALE

dito

 

 

 

Nur für Postgres gelten:

PGDATESTYLE

Datumsformat "German"

PGPORT

Port vom Postgres-Server, standardmäßig 5432

PGHOST

Hostname oder IP-Adresse vom Postgres-Server

PGUSER

Benutzerkennung für Postgres-Server (nur Datenbank, nicht Betriebssystem)

PGPATH

Installationsverzeichnis von Postgres, z.B. /usr/local/pgsql

DB_PROPERTIES

Pfad zur db-sos.properties-Datei mit den Zugangsparametern für SOSPOS unter Postgres

LOGGING_PROPERTIES

Pfad zur Steuerungsdatei mit den Parametern für das Logging beim Entladen, voreingestellt auf ./logging.properties. Normalerweise brauchen Sie hier nichts ändern, wenn beim Entladen Probleme auftauchen, kann man den Level von SEVERE auf INFO oder FINEST ändern, dann werden die konkreten SQLs geloggt. Aber Achtung: wenn keine Fehler mehr auftreten, müssen Sie den Level wieder auf SERVERE ändern, sonst kommen Schlüsselworte in die Logdatei sos_unload.err, die dann bei der Übernahme nach SuperX fälschlicherweise zu Fehlermeldungen führen.

 

Unter Postgres muss für das "Pull"-Verfahren beim Entladen die Datenbankverbindung in der Datei db-sos.properties eingetragen werden (Muster für Postgres liegt bei in db-sos_pg.properties). Dazu laden Sie einmal die Datei SOS_ENV mit den obigen Parameter, starten den SuperX-Propadmin (siehe Administrationshandbuch Kernmodul) und richten die Verbindung zum SOSPOS-Server ein. Das Kennwort wird verschlüsselt gespeichert. Danach sind die Entladescripte für Postgres ausführbar.

Hinweis: Anders als Informix hat Postgres hat eine eigene, vom Basissystem unabhängige Benutzerverwaltung. Daher brauchen Sie den User, den Sie zum Entladen aus Postgres nutzen, nicht auf dem SuperX- oder SOSPOS-Rechner auf Betriebssystem-Ebene einrichten. Sie können also z.B. auf dem SuperX-Rechner zum Entladen aus SOSPOS die Kennung sospos des Postgres- Rechners verwenden. Oder Sie richten in der SOSPOS -Datenbank den Benutzer SuperX ein und geben ihm Leserecht auf die Tabellen sowie das Recht, Tabellen und Stored Procedures anzulegen.

 

Für alle Platformen gelten folgende Variablen:

SX_CLIENT

Entladeprogramm für SOSPOS-DB: dbaccess, psql oder jdbc

DATABASE

Entladedatenbank der SOSPOS-DB: INFORMIX, POSTGRES, ACCESS

VERSION

Version von HISSOS (Ganzzahlig)

start_stud_sem

Beginn des Semesters, ab dem aus stg/sos entladen wird (Studierenden- und Fächersätze)

start_pruef_sem

Beginn des Semesters, ab dem aus lab/lsem entladen wird (Prüfungssätze)

SOS_UNL_COMPLETE

Sollen soll immer alles entladen werden (true). False bedeutet, dass nur die jeweils am Vortag geänderten Sätze entladen werden (inkrementelles Entladen). Dieser Schalter ist wichtig für die Übernahme: In SOS archivierte Sätze bleiben in SuperX erhalten, wenn inkrementell entladen wird. Wenn immer aus SOS komplett entladen wird, und die Archivierung in SuperX-SOS nicht aktiviert ist, dann werden alle Datenbestände in SuperX ausgetauscht, d.h in SOS gelöschte oder archivierte Sätze werden auch in SuperX gelöscht.
Generell ist es sicherer, immer komplett zu entladen. Der Update auf SuperX-Seite dauert allerdings dann auch länger.

TRANSACTION_OFF

Nur für Informix und bei Entladen mit "SOS_UNL_COMPLETE=false": Wenn Transaktionen eingeschaltet sind und die Protokoll-Tabellen groß sind, dann sollte dieses wie folgt belegt sein.
TRANSACTION_OFF="SET ISOLATION TO DIRTY READ;"

SOS_UNL_ANON

Namen werden sowieso nicht aus SOS entladen, aber sollen auch die Daten bzgl. matrikelnr anonymisiert werden? ('true'/'false')

Wenn Sie 'true' wählen, werden in der Zusatztabelle mtknr_lsdg Matrikelnummern eindeutig gefüllt

POS_PNR

Welche Prüfungsnummern außer denen die in der Tabelle hskonst in SOS für Hauptdiplom, Vordiplom und sonstige Prüfungsnummern verzeichnet sind, sollen ebenfalls entladen werden? Setzen Sie hier eine "0", dann werden alle Prüfungen entladen (Vorsicht: viele Daten!).
Sie können auch weitere PNRs als Vor- oder Hauptprüfung deklarieren.
Ein Beispiel für weitere Prüfungen wäre z.B.:
POS_PNR='9390,9490,9690,9700'

LAB_FILTER

Zusätzliche Filter für Einzelprüfungen (SQL-where Bedingung). Standardmäßig werden anerkannte Prüfungen gefiltert mit dem Ausdruck:
AND (lab.panerk is null or lab.panerk != 'J')
Sie können diesen Filter erweitern oder entfernen (Achtung: SQL-Syntax beachten).

ERRORMAIL

An wen solle eine Logmail verschickt werden, wenn das Entladen nicht geklappt hat? (nur Unix).

LOGMAIL

An wen soll immer eine Logmail verschickt werden

MAILPROG

Pfad zum ausführbaren Mailprogramm unter Unix, Vorbelegung ist "mail", manche Unixe haben aber auch "mutt".

 

 

 

Wenn die Rohdaten nach dem Entladen vom SOS-Rechner auf den SuperX-Rechner kopiert werden sollen, dann werden für das Script sos_copy.x folgende Umgebungsvariablen benötigt:

COPY_METHOD

Programm, das die Dateien kopiert; rsync und scp sind wählbar.

REMOTE_DIR

Verzeichnis, in das die Rohdaten auf dem SuperX-Rechner kopiert warden sollen, in der Regel ist dies "/home/superx/db/module/sos/rohdaten"

REMOTE_USER

Der Unix-Username auf dem SuperX-Rechner, in der Regel "superx".

REMOTE_HOST

Der Rechnername bzw. die IP-Nr. des SuperX-Rechners.

 

Nach der Konfiguration muss einmal in der SOS-Datenbank das Script superx_sos_install.x ausgeführt werden, es wird eine Tabelle zur Pseudonymisierung von Matrikelnummern installiert.

Wenn Sie Informix oder Postgres unter Windows benutzen, können Sie das Script nicht ausführen. Setzen Sie stattdessen einmalig das SQL-Kommando ab:

Manuelles Anlegen der Pseudonymisierungstabelle

create table mtknr_ldsg

(

mtknr integer,

mtknr_ldsg serial

);

create unique index i_mtknr_1 on mtknr_ldsg (mtknr);

 

Mehr macht das Script superx_sos_install.x  auch nicht.

 

Wenn "SOS_UNL_COMPLETE=false" gesetzt ist, dann muss darüberhinaus in der Datei
superx.datum der Stichtag des Entladens angegeben werden, d.h. alle Sätze zu Matrikelnummern werden entladen, die in die Protokolltabellen pprot, pro eingetragen werden und nach dem Stichtag aufgetreten sind.

Defaultmäßig entlädt SuperX danach immer nur die Änderungen. Dies macht es aber erforderlicht, dass das Rohdaten-Verzeichnis auf dem SuperX-Rechner gemounted ist bzw. die Datei superx.datum nach dem Update auf SuperX-Seite regelmäßg rückgeschrieben wird. Wenn nämlich der Update auf SuperX-Seite mit Fehler beendet hat, dann wird das Entladedatum auf das vorherige Datum (superx.datum.alt) zurückgesetzt, damit beim nächsten Entladen die Sätze erneut übernommen werden.

Dieser Prozeß ist gerade in der Installationsphase recht fehlerträchtig, deshalb gibt es auch die Möglichkeit, die SOS-Daten immer komplett zu entladen. Dazu muss in SOS_ENV die Umgebungsvariable SOS_UNL_COMPLETE auf "true" gesetzt werden.

Dann starten Sie das Script sos_unload.x. Wenn es gelaufen ist, müssten die Dateien im unl-Verzeichnis stehen. Prüfen Sie dann bitte, ob dort Dateien mit 0 bytes stehen. Die Logdatei heisst sos_unload.err.

Wenn Sie das Verzeichnis nicht gemounted haben, müssen das Verzeichnis unl, die sos_unload.err und die superx.datum  dann in das Verzeichnis $SOS_LOAD_PFAD auf dem SuperX-Rechner kopiert werden, ein Script dafür liegt ebenfalls bei (sos_copy.x)[3]. Das Entladedatum wird danach in der Textdatei $SOS_LOAD_PFAD/superx.datum gespeichert; wenn das Script einen Fehler findet, dann wird das vorherige Datum (in der Datei superx.datum.alt) gesetzt.


Zur Superx-Homepage SuperX ist auch ein CampusSource-Projekt. Zur CampusSource-Homepage | Powered by FreeMarker Seite 13 / 98
Letzter Update: 23.06.2010
Impressum